Реализация gRPC-метода RegisterUser в auth-service

Хэширование пароля, создание записи в PostgreSQL без FK-ограничений, динамическое ветвление пространств и генерация TokenPair.

Author

Services Task & Simulation Framework Documentation

Published

July 13, 2026

NoteКраткая карточка задачи
  • Репозиторий / Компонент: auth-service (Backend контура авторизации).
  • Категория: Бэкенд.
  • Контракт методов: gRPC rpc RegisterUser(RegisterRequest) returns (RegisterResponse);
  • Спецификация контракта: См. Раздел: Protobuf Контракт: RegisterUser
  • Статус: Готово к реализации

WarningОграничение публичной документации

В открытом доступе представлена демонстрационная версия задачи. В настоящей публичной документации отображены не все шаги, технические сценарии и приватные эндпоинты для системы цифровых симуляторов бизнес-процессов.

  • Полная спецификация метода: Доступна только во внутреннем контуре разработки (Confluence / Swagger Enterprise).
  • Для получения доступа: Обратитесь к системному аналитику или Product Owner вашей команды.

  • Предварительные условия (Prerequisites):
    1. Убедиться, что DDL-миграции таблиц auth_db.users (IAD-MIGRATION-119) и auth_db.sessions (IAD-MIGRATION-120) успешно применены в СУБД.
    2. Обновить сгенерированные серверные gRPC-стабы на основе файла контракта.
  • Инструкция по шагам:
    1. На Шаге 3 (Валидация): Реализовать gRPC-хэндлер RegisterUser. Если email или password не переданы или нарушают формат структуры, прерывать выполнение с ошибкой gRPC Status: INVALID_ARGUMENT.

    2. На Шаге 4 (Проверка и создание профиля): Открыть атомарную транзакцию. Проверить уникальность email. Если запись существует, возвращать бизнес-исключение gRPC Status: ALREADY_EXISTS (код ошибки ERR_EMAIL_ALREADY_EXISTS). Выполнить хэширование пароля в памяти (Bcrypt/Argon2) и выполнить команду INSERT INTO auth_db.users.

    3. На Шаге 6 (Изолированное ветвление пространств): На основе флага space_creation_mode выполнить прикладную логику:

      • При режимах CREATE_NEW_HOME / CREATE_NEW_OFFICE сгенерировать UUID для home_group_id и зафиксировать соответствующий флаг account_type.
      • При JOIN_EXISTING проверить статус invite_token. При ошибке возвращать статус NOT_FOUND (код ERR_INVITE_TOKEN_INVALID). Привязать UUID нового пользователя к существующей группе.
    4. На Шаге 7 (Фиксация сессии без FK): Сгенерировать пару токенов, внедрив контекст группы в JWT Claims. Рассчитать SHA-256 хэш от созданного Refresh-токена и записать его в таблицу auth_db.sessions.

      ImportantАрхитектурное требование

      Связывание user_sessions.user_id с таблицей users производить исключительно на уровне прикладного кода приложения. Использование физических внешних ключей (FOREIGN KEY) СУБД запрещено для сохранения изоляции микросервисов.

    5. Ответ (Шаг 8): Закоммитить транзакцию PostgreSQL и вернуть шлюзу структуру RegisterResponse.